Restrict data access with Access Filters

Using Access Filters, you may restrict data access to users:

• Enable each view - HTTP, TCP, PACKET - independently,
• Restrict accessible data with a specific filter using Lucene syntax.
• Remove the HTTP headers you do not want to expose to certain users
• Remove access to the HTTP payloads
  • Useful to get access to statistics and patterns without having access to confidential data
• Define a set of filters as default for new team members

info

Access filters are integrated in the tokens and are applied in the backend.
They are applied on all APIs used to retrieve captured data.
This prevents any privilege escalation and ensure the correct application of any usage restriction.

Access filters tab

Required rights

To manage Access Filters, you need to have the Share rights in the team. That is to say, the right to add Users to the team.

Creating an Access Filter

To create an Access Filter:

1. Open the Team owning the target Whisperers
2. Go to Access filters tab
3. Click on NEW ACCESS FILTER

4. The Access Filter form opens

5. Fill in the form

6. Click save

The filter will apply for all selected users next time they select the Team.

Access filter fields explanation

Fields common to all views:

Field	Description
Team	Name of the team for this Access Filter. Prefilled.
Name	Name of the Access Filter. Will be displayed in the selected filters.
Description	Any description for this filter.
Whisperer	One to many Whisperers this access filter applies to.
View	The View this filter applies to. HTTP, TCP or PACKET.
Access view	Allows to forbid completely the access to the view data.
Access filter	Defines the filter, in Lucene syntax. Autocompletion is available, and you may also copy currently active filters from the UI.
Default for new users	When set, this filter will be associated to any new user joining or added to the team.

HTTP view adds a few filtering options:

Field	Description
Access payloads	Tells if the user will have access to request and response bodies, as well as raw request and response headers.
Hide headers	List of HTTP headers to remove when sending the HTTP communication (raw or as an object) to the user.

Viewing and editing existing Access Filters

Once created, the filter is added to the team and accessible from the Access filters tab.
You may edit it (same form as above) as remove it.

Access filters are folded by default, and may be expanded by clicking on their title.

The bottom part of the tab allows you to associate users to the existing Access Filters, as in the Users tab.
This matrix display enables an easy control of the consistency of Access Filters association across the team.

Users are orders by their date of joining the team.

Seeing access filters to are applied

When a user associated to Access Filters selects one of the filter Whisperers, a badge is displayed next to the Team and Whisperer badges:

It tells what filter applied, and shows a lock icon, indicating that the filters cannot be removed.
A tooltip explains the filters applied.

Sample use cases

Give production data access to developers without leaking production access

Given a system:

• Using POST /authenticate API to authenticate users using login and password inputs
• Building a JWT token to enable further authentication
  • Like most modern systems
• Using the JWT token in the Authorization HTTP header to transmit it in the system services

Access Filter feature of Spider allows you to give access to 'non administrator' users to the system exchanges without risking credentials leak and without allowing them to steal and reuse the tokens.

To do this, create an Access Filter:

• on HTTP View
• hiding the Authorization HTTP headers
• using a query filter to prevent seeing the authentication calls: NOT req.uri:"POST /authenticate"
• set it as Default filter so that any new users gets it by default

Give production statistics and behavior access to developers without giving data access

In the same system, you may want your developers to:

• extract production statistics
• study usage behaviors
• evaluate new release impacts

All this using Spider, but without giving access to raw data.

To do this, create another Access Filter:

• on HTTP View
• hiding the Authorization HTTP headers
• without access to HTTP payloads

Note that:

• No need to hide the authentication calls as data payloads are not accessible.
• As it is not a default filter, you have to specify the users list.

Allow high level access without giving low level access

On the same system, you want to capture TCP sessions and Network Packets before of some network instability to troubleshoot.
If users have access to low level captured data, they will be able to obtain credentials hidden at higher level.

To protect against it, create 2 other Access Filter:

• on TCP and PACKET Views
• with no access at all
• set them as default

This way, any new user will not have access to low level, while still having access to high level data, with safe and control access.

Allow restricted access in production to a product squad checking or troubleshooting a new deployment

On this system, the 'EV' squad works on a brand new set of services and they want to control their behavior after their first deployment.

To do this, create an Access Filter:

• on HTTP View
• hiding the Authorization HTTP headers
• using a query filter:
  • to prevent seeing the authentication calls: NOT req.uri:"POST /authenticate"
  • to restrict access to services which names starts by 'ev-': stats.src.name:ev-* OR stats.dst.name:ev-*
• associate the ev squad team members to the Access Filter